<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">


<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
    
    <title>Writing and running tests &mdash; Django 1.7.8.dev20150401230226 documentation</title>
    
    <link rel="stylesheet" href="../../_static/default.css" type="text/css" />
    <link rel="stylesheet" href="../../_static/pygments.css" type="text/css" />
    
    <script type="text/javascript">
      var DOCUMENTATION_OPTIONS = {
        URL_ROOT:    '../../',
        VERSION:     '1.7.8.dev20150401230226',
        COLLAPSE_INDEX: false,
        FILE_SUFFIX: '.html',
        HAS_SOURCE:  true
      };
    </script>
    <script type="text/javascript" src="../../_static/jquery.js"></script>
    <script type="text/javascript" src="../../_static/underscore.js"></script>
    <script type="text/javascript" src="../../_static/doctools.js"></script>
    <link rel="top" title="Django 1.7.8.dev20150401230226 documentation" href="../../index.html" />
    <link rel="up" title="Testing in Django" href="index.html" />
    <link rel="next" title="Testing tools" href="tools.html" />
    <link rel="prev" title="Testing in Django" href="index.html" />



 
<script type="text/javascript" src="../../templatebuiltins.js"></script>
<script type="text/javascript">
(function($) {
    if (!django_template_builtins) {
       // templatebuiltins.js missing, do nothing.
       return;
    }
    $(document).ready(function() {
        // Hyperlink Django template tags and filters
        var base = "../../ref/templates/builtins.html";
        if (base == "#") {
            // Special case for builtins.html itself
            base = "";
        }
        // Tags are keywords, class '.k'
        $("div.highlight\\-html\\+django span.k").each(function(i, elem) {
             var tagname = $(elem).text();
             if ($.inArray(tagname, django_template_builtins.ttags) != -1) {
                 var fragment = tagname.replace(/_/, '-');
                 $(elem).html("<a href='" + base + "#" + fragment + "'>" + tagname + "</a>");
             }
        });
        // Filters are functions, class '.nf'
        $("div.highlight\\-html\\+django span.nf").each(function(i, elem) {
             var filtername = $(elem).text();
             if ($.inArray(filtername, django_template_builtins.tfilters) != -1) {
                 var fragment = filtername.replace(/_/, '-');
                 $(elem).html("<a href='" + base + "#" + fragment + "'>" + filtername + "</a>");
             }
        });
    });
})(jQuery);
</script>


  </head>
  <body>

    <div class="document">
  <div id="custom-doc" class="yui-t6">
    <div id="hd">
      <h1><a href="../../index.html">Django 1.7.8.dev20150401230226 documentation</a></h1>
      <div id="global-nav">
        <a title="Home page" href="../../index.html">Home</a>  |
        <a title="Table of contents" href="../../contents.html">Table of contents</a>  |
        <a title="Global index" href="../../genindex.html">Index</a>  |
        <a title="Module index" href="../../py-modindex.html">Modules</a>
      </div>
      <div class="nav">
    &laquo; <a href="index.html" title="Testing in Django">previous</a>
     |
    <a href="../index.html" title="Using Django" accesskey="U">up</a>
   |
    <a href="tools.html" title="Testing tools">next</a> &raquo;</div>
    </div>

    <div id="bd">
      <div id="yui-main">
        <div class="yui-b">
          <div class="yui-g" id="topics-testing-overview">
            
  <div class="section" id="s-module-django.test">
<span id="s-writing-and-running-tests"></span><span id="module-django.test"></span><span id="writing-and-running-tests"></span><h1>Writing and running tests<a class="headerlink" href="#module-django.test" title="Permalink to this headline">¶</a></h1>
<div class="admonition seealso">
<p class="first admonition-title">See also</p>
<p class="last">The <a class="reference internal" href="../../intro/tutorial05.html"><em>testing tutorial</em></a>, the <a class="reference internal" href="tools.html"><em>testing tools
reference</em></a>, and the <a class="reference internal" href="advanced.html"><em>advanced testing topics</em></a>.</p>
</div>
<p>This document is split into two primary sections. First, we explain how to write
tests with Django. Then, we explain how to run them.</p>
<div class="section" id="s-writing-tests">
<span id="writing-tests"></span><h2>Writing tests<a class="headerlink" href="#writing-tests" title="Permalink to this headline">¶</a></h2>
<p>Django&#8217;s unit tests use a Python standard library module: <a class="reference external" href="http://docs.python.org/3/library/unittest.html#module-unittest" title="(in Python v3.4)"><tt class="xref py py-mod docutils literal"><span class="pre">unittest</span></tt></a>. This
module defines tests using a class-based approach.</p>
<div class="admonition-unittest2 admonition">
<p class="first admonition-title">unittest2</p>
<div class="deprecated">
<p><span class="versionmodified">Deprecated since version 1.7.</span></p>
</div>
<p>Python 2.7 introduced some major changes to the <tt class="docutils literal"><span class="pre">unittest</span></tt> library,
adding some extremely useful features. To ensure that every Django project
could benefit from these new features, Django used to ship with a copy of
Python 2.7&#8217;s <tt class="docutils literal"><span class="pre">unittest</span></tt> backported for Python 2.6 compatibility.</p>
<p class="last">Since Django no longer supports Python versions older than 2.7,
<tt class="docutils literal"><span class="pre">django.utils.unittest</span></tt> is deprecated. Simply use <tt class="docutils literal"><span class="pre">unittest</span></tt>.</p>
</div>
<p>Here is an example which subclasses from <a class="reference internal" href="tools.html#django.test.TestCase" title="django.test.TestCase"><tt class="xref py py-class docutils literal"><span class="pre">django.test.TestCase</span></tt></a>,
which is a subclass of <a class="reference external" href="http://docs.python.org/3/library/unittest.html#unittest.TestCase" title="(in Python v3.4)"><tt class="xref py py-class docutils literal"><span class="pre">unittest.TestCase</span></tt></a> that runs each test inside a
transaction to provide isolation:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="kn">from</span> <span class="nn">django.test</span> <span class="kn">import</span> <span class="n">TestCase</span>
<span class="kn">from</span> <span class="nn">myapp.models</span> <span class="kn">import</span> <span class="n">Animal</span>

<span class="k">class</span> <span class="nc">AnimalTestCase</span><span class="p">(</span><span class="n">TestCase</span><span class="p">):</span>
    <span class="k">def</span> <span class="nf">setUp</span><span class="p">(</span><span class="bp">self</span><span class="p">):</span>
        <span class="n">Animal</span><span class="o">.</span><span class="n">objects</span><span class="o">.</span><span class="n">create</span><span class="p">(</span><span class="n">name</span><span class="o">=</span><span class="s">&quot;lion&quot;</span><span class="p">,</span> <span class="n">sound</span><span class="o">=</span><span class="s">&quot;roar&quot;</span><span class="p">)</span>
        <span class="n">Animal</span><span class="o">.</span><span class="n">objects</span><span class="o">.</span><span class="n">create</span><span class="p">(</span><span class="n">name</span><span class="o">=</span><span class="s">&quot;cat&quot;</span><span class="p">,</span> <span class="n">sound</span><span class="o">=</span><span class="s">&quot;meow&quot;</span><span class="p">)</span>

    <span class="k">def</span> <span class="nf">test_animals_can_speak</span><span class="p">(</span><span class="bp">self</span><span class="p">):</span>
        <span class="sd">&quot;&quot;&quot;Animals that can speak are correctly identified&quot;&quot;&quot;</span>
        <span class="n">lion</span> <span class="o">=</span> <span class="n">Animal</span><span class="o">.</span><span class="n">objects</span><span class="o">.</span><span class="n">get</span><span class="p">(</span><span class="n">name</span><span class="o">=</span><span class="s">&quot;lion&quot;</span><span class="p">)</span>
        <span class="n">cat</span> <span class="o">=</span> <span class="n">Animal</span><span class="o">.</span><span class="n">objects</span><span class="o">.</span><span class="n">get</span><span class="p">(</span><span class="n">name</span><span class="o">=</span><span class="s">&quot;cat&quot;</span><span class="p">)</span>
        <span class="bp">self</span><span class="o">.</span><span class="n">assertEqual</span><span class="p">(</span><span class="n">lion</span><span class="o">.</span><span class="n">speak</span><span class="p">(),</span> <span class="s">&#39;The lion says &quot;roar&quot;&#39;</span><span class="p">)</span>
        <span class="bp">self</span><span class="o">.</span><span class="n">assertEqual</span><span class="p">(</span><span class="n">cat</span><span class="o">.</span><span class="n">speak</span><span class="p">(),</span> <span class="s">&#39;The cat says &quot;meow&quot;&#39;</span><span class="p">)</span>
</pre></div>
</div>
<p>When you <a class="reference internal" href="#running-tests"><em>run your tests</em></a>, the default behavior of the
test utility is to find all the test cases (that is, subclasses of
<a class="reference external" href="http://docs.python.org/3/library/unittest.html#unittest.TestCase" title="(in Python v3.4)"><tt class="xref py py-class docutils literal"><span class="pre">unittest.TestCase</span></tt></a>) in any file whose name begins with <tt class="docutils literal"><span class="pre">test</span></tt>,
automatically build a test suite out of those test cases, and run that suite.</p>
<div class="versionchanged">
<span class="title">Changed in Django 1.6:</span> <p>Previously, Django&#8217;s default test runner only discovered tests in
<tt class="docutils literal"><span class="pre">tests.py</span></tt> and <tt class="docutils literal"><span class="pre">models.py</span></tt> files within a Python package listed in
<a class="reference internal" href="../../ref/settings.html#std:setting-INSTALLED_APPS"><tt class="xref std std-setting docutils literal"><span class="pre">INSTALLED_APPS</span></tt></a>.</p>
</div>
<p>For more details about <a class="reference external" href="http://docs.python.org/3/library/unittest.html#module-unittest" title="(in Python v3.4)"><tt class="xref py py-mod docutils literal"><span class="pre">unittest</span></tt></a>, see the Python documentation.</p>
<div class="admonition warning">
<p class="first admonition-title">Warning</p>
<p>If your tests rely on database access such as creating or querying models,
be sure to create your test classes as subclasses of
<a class="reference internal" href="tools.html#django.test.TestCase" title="django.test.TestCase"><tt class="xref py py-class docutils literal"><span class="pre">django.test.TestCase</span></tt></a> rather than <a class="reference external" href="http://docs.python.org/3/library/unittest.html#unittest.TestCase" title="(in Python v3.4)"><tt class="xref py py-class docutils literal"><span class="pre">unittest.TestCase</span></tt></a>.</p>
<p class="last">Using <a class="reference external" href="http://docs.python.org/3/library/unittest.html#unittest.TestCase" title="(in Python v3.4)"><tt class="xref py py-class docutils literal"><span class="pre">unittest.TestCase</span></tt></a> avoids the cost of running each test in a
transaction and flushing the database, but if your tests interact with
the database their behavior will vary based on the order that the test
runner executes them. This can lead to unit tests that pass when run in
isolation but fail when run in a suite.</p>
</div>
</div>
<div class="section" id="s-running-tests">
<span id="s-id1"></span><span id="running-tests"></span><span id="id1"></span><h2>Running tests<a class="headerlink" href="#running-tests" title="Permalink to this headline">¶</a></h2>
<p>Once you&#8217;ve written tests, run them using the <a class="reference internal" href="../../ref/django-admin.html#django-admin-test"><tt class="xref std std-djadmin docutils literal"><span class="pre">test</span></tt></a> command of
your project&#8217;s <tt class="docutils literal"><span class="pre">manage.py</span></tt> utility:</p>
<div class="highlight-python"><div class="highlight"><pre>$ ./manage.py test
</pre></div>
</div>
<p>Test discovery is based on the unittest module&#8217;s <a class="reference external" href="http://docs.python.org/3/library/unittest.html#unittest-test-discovery" title="(in Python v3.4)"><em class="xref std std-ref">built-in test
discovery</em></a>.  By default, this will discover tests in
any file named &#8220;test*.py&#8221; under the current working directory.</p>
<p>You can specify particular tests to run by supplying any number of &#8220;test
labels&#8221; to <tt class="docutils literal"><span class="pre">./manage.py</span> <span class="pre">test</span></tt>. Each test label can be a full Python dotted
path to a package, module, <tt class="docutils literal"><span class="pre">TestCase</span></tt> subclass, or test method. For instance:</p>
<div class="highlight-python"><div class="highlight"><pre># Run all the tests in the animals.tests module
$ ./manage.py test animals.tests

# Run all the tests found within the &#39;animals&#39; package
$ ./manage.py test animals

# Run just one test case
$ ./manage.py test animals.tests.AnimalTestCase

# Run just one test method
$ ./manage.py test animals.tests.AnimalTestCase.test_animals_can_speak
</pre></div>
</div>
<p>You can also provide a path to a directory to discover tests below that
directory:</p>
<div class="highlight-python"><div class="highlight"><pre>$ ./manage.py test animals/
</pre></div>
</div>
<p>You can specify a custom filename pattern match using the <tt class="docutils literal"><span class="pre">-p</span></tt> (or
<tt class="docutils literal"><span class="pre">--pattern</span></tt>) option, if your test files are named differently from the
<tt class="docutils literal"><span class="pre">test*.py</span></tt> pattern:</p>
<div class="highlight-python"><div class="highlight"><pre>$ ./manage.py test --pattern=&quot;tests_*.py&quot;
</pre></div>
</div>
<div class="versionchanged">
<span class="title">Changed in Django 1.6:</span> <p>Previously, test labels were in the form <tt class="docutils literal"><span class="pre">applabel</span></tt>,
<tt class="docutils literal"><span class="pre">applabel.TestCase</span></tt>, or <tt class="docutils literal"><span class="pre">applabel.TestCase.test_method</span></tt>, rather than
being true Python dotted paths, and tests could only be found within
<tt class="docutils literal"><span class="pre">tests.py</span></tt> or <tt class="docutils literal"><span class="pre">models.py</span></tt> files within a Python package listed in
<a class="reference internal" href="../../ref/settings.html#std:setting-INSTALLED_APPS"><tt class="xref std std-setting docutils literal"><span class="pre">INSTALLED_APPS</span></tt></a>. The <tt class="docutils literal"><span class="pre">--pattern</span></tt> option and file paths as test
labels are new in 1.6.</p>
</div>
<p>If you press <tt class="docutils literal"><span class="pre">Ctrl-C</span></tt> while the tests are running, the test runner will
wait for the currently running test to complete and then exit gracefully.
During a graceful exit the test runner will output details of any test
failures, report on how many tests were run and how many errors and failures
were encountered, and destroy any test databases as usual. Thus pressing
<tt class="docutils literal"><span class="pre">Ctrl-C</span></tt> can be very useful if you forget to pass the <a class="reference internal" href="../../ref/django-admin.html#django-admin-option---failfast"><tt class="xref std std-djadminopt docutils literal"><span class="pre">--failfast</span></tt></a>
option, notice that some tests are unexpectedly failing, and want to get details
on the failures without waiting for the full test run to complete.</p>
<p>If you do not want to wait for the currently running test to finish, you
can press <tt class="docutils literal"><span class="pre">Ctrl-C</span></tt> a second time and the test run will halt immediately,
but not gracefully. No details of the tests run before the interruption will
be reported, and any test databases created by the run will not be destroyed.</p>
<div class="admonition-test-with-warnings-enabled admonition">
<p class="first admonition-title">Test with warnings enabled</p>
<p class="last">It&#8217;s a good idea to run your tests with Python warnings enabled:
<tt class="docutils literal"><span class="pre">python</span> <span class="pre">-Wall</span> <span class="pre">manage.py</span> <span class="pre">test</span></tt>. The <tt class="docutils literal"><span class="pre">-Wall</span></tt> flag tells Python to
display deprecation warnings. Django, like many other Python libraries,
uses these warnings to flag when features are going away. It also might
flag areas in your code that aren&#8217;t strictly wrong but could benefit
from a better implementation.</p>
</div>
<div class="section" id="s-the-test-database">
<span id="s-id2"></span><span id="the-test-database"></span><span id="id2"></span><h3>The test database<a class="headerlink" href="#the-test-database" title="Permalink to this headline">¶</a></h3>
<p>Tests that require a database (namely, model tests) will not use your &#8220;real&#8221;
(production) database. Separate, blank databases are created for the tests.</p>
<p>Regardless of whether the tests pass or fail, the test databases are destroyed
when all the tests have been executed.</p>
<p>By default the test databases get their names by prepending <tt class="docutils literal"><span class="pre">test_</span></tt>
to the value of the <a class="reference internal" href="../../ref/settings.html#std:setting-NAME"><tt class="xref std std-setting docutils literal"><span class="pre">NAME</span></tt></a> settings for the databases
defined in <a class="reference internal" href="../../ref/settings.html#std:setting-DATABASES"><tt class="xref std std-setting docutils literal"><span class="pre">DATABASES</span></tt></a>. When using the SQLite database engine
the tests will by default use an in-memory database (i.e., the
database will be created in memory, bypassing the filesystem
entirely!). If you want to use a different database name, specify
<a class="reference internal" href="../../ref/settings.html#std:setting-TEST_NAME"><tt class="xref std std-setting docutils literal"><span class="pre">NAME</span></tt></a> in the <a class="reference internal" href="../../ref/settings.html#std:setting-DATABASE-TEST"><tt class="xref std std-setting docutils literal"><span class="pre">TEST</span></tt></a>
dictionary for any given database in <a class="reference internal" href="../../ref/settings.html#std:setting-DATABASES"><tt class="xref std std-setting docutils literal"><span class="pre">DATABASES</span></tt></a>.</p>
<div class="versionchanged">
<span class="title">Changed in Django 1.7:</span> <p>On PostgreSQL, <a class="reference internal" href="../../ref/settings.html#std:setting-USER"><tt class="xref std std-setting docutils literal"><span class="pre">USER</span></tt></a> will also need read access to the built-in
<tt class="docutils literal"><span class="pre">postgres</span></tt> database.</p>
</div>
<p>Aside from using a separate database, the test runner will otherwise
use all of the same database settings you have in your settings file:
<a class="reference internal" href="../../ref/settings.html#std:setting-DATABASE-ENGINE"><tt class="xref std std-setting docutils literal"><span class="pre">ENGINE</span></tt></a>, <a class="reference internal" href="../../ref/settings.html#std:setting-USER"><tt class="xref std std-setting docutils literal"><span class="pre">USER</span></tt></a>, <a class="reference internal" href="../../ref/settings.html#std:setting-HOST"><tt class="xref std std-setting docutils literal"><span class="pre">HOST</span></tt></a>, etc. The
test database is created by the user specified by <a class="reference internal" href="../../ref/settings.html#std:setting-USER"><tt class="xref std std-setting docutils literal"><span class="pre">USER</span></tt></a>, so you&#8217;ll
need to make sure that the given user account has sufficient privileges to
create a new database on the system.</p>
<p>For fine-grained control over the character encoding of your test
database, use the <a class="reference internal" href="../../ref/settings.html#std:setting-TEST_CHARSET"><tt class="xref std std-setting docutils literal"><span class="pre">CHARSET</span></tt></a> TEST option. If you&#8217;re using
MySQL, you can also use the <a class="reference internal" href="../../ref/settings.html#std:setting-TEST_COLLATION"><tt class="xref std std-setting docutils literal"><span class="pre">COLLATION</span></tt></a> option to
control the particular collation used by the test database. See the
<a class="reference internal" href="../../ref/settings.html"><em>settings documentation</em></a> for details of these
and other advanced settings.</p>
<div class="versionchanged">
<span class="title">Changed in Django 1.7:</span> <p>The different options in the <a class="reference internal" href="../../ref/settings.html#std:setting-DATABASE-TEST"><tt class="xref std std-setting docutils literal"><span class="pre">TEST</span></tt></a> database
setting used to be separate options in the database settings dictionary,
prefixed with <tt class="docutils literal"><span class="pre">TEST_</span></tt>.</p>
</div>
<div class="admonition-finding-data-from-your-production-database-when-running-tests admonition">
<p class="first admonition-title">Finding data from your production database when running tests?</p>
<p>If your code attempts to access the database when its modules are compiled,
this will occur <em>before</em> the test database is set up, with potentially
unexpected results. For example, if you have a database query in
module-level code and a real database exists, production data could pollute
your tests. <em>It is a bad idea to have such import-time database queries in
your code</em> anyway - rewrite your code so that it doesn&#8217;t do this.</p>
<div class="last versionadded">
<span class="title">New in Django 1.7:</span> <p>This also applies to customized implementations of
<a class="reference internal" href="../../ref/applications.html#django.apps.AppConfig.ready" title="django.apps.AppConfig.ready"><tt class="xref py py-meth docutils literal"><span class="pre">ready()</span></tt></a>.</p>
</div>
</div>
<div class="admonition seealso">
<p class="first admonition-title">See also</p>
<p class="last">The <a class="reference internal" href="advanced.html#topics-testing-advanced-multidb"><em>advanced multi-db testing topics</em></a>.</p>
</div>
</div>
<div class="section" id="s-order-in-which-tests-are-executed">
<span id="s-order-of-tests"></span><span id="order-in-which-tests-are-executed"></span><span id="order-of-tests"></span><h3>Order in which tests are executed<a class="headerlink" href="#order-in-which-tests-are-executed" title="Permalink to this headline">¶</a></h3>
<p>In order to guarantee that all <tt class="docutils literal"><span class="pre">TestCase</span></tt> code starts with a clean database,
the Django test runner reorders tests in the following way:</p>
<ul class="simple">
<li>All <a class="reference internal" href="tools.html#django.test.TestCase" title="django.test.TestCase"><tt class="xref py py-class docutils literal"><span class="pre">TestCase</span></tt></a> subclasses are run first.</li>
<li>Then, all other Django-based tests (test cases based on
<a class="reference internal" href="tools.html#django.test.SimpleTestCase" title="django.test.SimpleTestCase"><tt class="xref py py-class docutils literal"><span class="pre">SimpleTestCase</span></tt></a>, including
<a class="reference internal" href="tools.html#django.test.TransactionTestCase" title="django.test.TransactionTestCase"><tt class="xref py py-class docutils literal"><span class="pre">TransactionTestCase</span></tt></a>) are run with no particular
ordering guaranteed nor enforced among them.</li>
<li>Then any other <a class="reference external" href="http://docs.python.org/3/library/unittest.html#unittest.TestCase" title="(in Python v3.4)"><tt class="xref py py-class docutils literal"><span class="pre">unittest.TestCase</span></tt></a> tests (including doctests) that may
alter the database without restoring it to its original state are run.</li>
</ul>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">The new ordering of tests may reveal unexpected dependencies on test case
ordering. This is the case with doctests that relied on state left in the
database by a given <a class="reference internal" href="tools.html#django.test.TransactionTestCase" title="django.test.TransactionTestCase"><tt class="xref py py-class docutils literal"><span class="pre">TransactionTestCase</span></tt></a> test, they
must be updated to be able to run independently.</p>
</div>
</div>
<div class="section" id="s-rollback-emulation">
<span id="s-test-case-serialized-rollback"></span><span id="rollback-emulation"></span><span id="test-case-serialized-rollback"></span><h3>Rollback emulation<a class="headerlink" href="#rollback-emulation" title="Permalink to this headline">¶</a></h3>
<p>Any initial data loaded in migrations will only be available in <tt class="docutils literal"><span class="pre">TestCase</span></tt>
tests and not in <tt class="docutils literal"><span class="pre">TransactionTestCase</span></tt> tests, and additionally only on
backends where transactions are supported (the most important exception being
MyISAM).</p>
<p>Django can reload that data for you on a per-testcase basis by
setting the <tt class="docutils literal"><span class="pre">serialized_rollback</span></tt> option to <tt class="docutils literal"><span class="pre">True</span></tt> in the body of the
<tt class="docutils literal"><span class="pre">TestCase</span></tt> or <tt class="docutils literal"><span class="pre">TransactionTestCase</span></tt>, but note that this will slow down
that test suite by approximately 3x.</p>
<p>Third-party apps or those developing against MyISAM will need to set this;
in general, however, you should be developing your own projects against a
transactional database and be using <tt class="docutils literal"><span class="pre">TestCase</span></tt> for most tests, and thus
not need this setting.</p>
<p>The initial serialization is usually very quick, but if you wish to exclude
some apps from this process (and speed up test runs slightly), you may add
those apps to <a class="reference internal" href="../../ref/settings.html#std:setting-TEST_NON_SERIALIZED_APPS"><tt class="xref std std-setting docutils literal"><span class="pre">TEST_NON_SERIALIZED_APPS</span></tt></a>.</p>
<p>Apps without migrations are not affected; <tt class="docutils literal"><span class="pre">initial_data</span></tt> fixtures are
reloaded as usual.</p>
</div>
<div class="section" id="s-other-test-conditions">
<span id="other-test-conditions"></span><h3>Other test conditions<a class="headerlink" href="#other-test-conditions" title="Permalink to this headline">¶</a></h3>
<p>Regardless of the value of the <a class="reference internal" href="../../ref/settings.html#std:setting-DEBUG"><tt class="xref std std-setting docutils literal"><span class="pre">DEBUG</span></tt></a> setting in your configuration
file, all Django tests run with <a class="reference internal" href="../../ref/settings.html#std:setting-DEBUG"><tt class="xref std std-setting docutils literal"><span class="pre">DEBUG</span></tt></a>=False. This is to ensure that
the observed output of your code matches what will be seen in a production
setting.</p>
<p>Caches are not cleared after each test, and running &#8220;manage.py test fooapp&#8221; can
insert data from the tests into the cache of a live system if you run your
tests in production because, unlike databases, a separate &#8220;test cache&#8221; is not
used. This behavior <a class="reference external" href="https://code.djangoproject.com/ticket/11505">may change</a> in the future.</p>
</div>
<div class="section" id="s-understanding-the-test-output">
<span id="understanding-the-test-output"></span><h3>Understanding the test output<a class="headerlink" href="#understanding-the-test-output" title="Permalink to this headline">¶</a></h3>
<p>When you run your tests, you&#8217;ll see a number of messages as the test runner
prepares itself. You can control the level of detail of these messages with the
<tt class="docutils literal"><span class="pre">verbosity</span></tt> option on the command line:</p>
<div class="highlight-python"><div class="highlight"><pre>Creating test database...
Creating table myapp_animal
Creating table myapp_mineral
Loading &#39;initial_data&#39; fixtures...
No fixtures found.
</pre></div>
</div>
<p>This tells you that the test runner is creating a test database, as described
in the previous section.</p>
<p>Once the test database has been created, Django will run your tests.
If everything goes well, you&#8217;ll see something like this:</p>
<div class="highlight-python"><div class="highlight"><pre>----------------------------------------------------------------------
Ran 22 tests in 0.221s

OK
</pre></div>
</div>
<p>If there are test failures, however, you&#8217;ll see full details about which tests
failed:</p>
<div class="highlight-python"><div class="highlight"><pre>======================================================================
FAIL: test_was_published_recently_with_future_poll (polls.tests.PollMethodTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File &quot;/dev/mysite/polls/tests.py&quot;, line 16, in test_was_published_recently_with_future_poll
    self.assertEqual(future_poll.was_published_recently(), False)
AssertionError: True != False

----------------------------------------------------------------------
Ran 1 test in 0.003s

FAILED (failures=1)
</pre></div>
</div>
<p>A full explanation of this error output is beyond the scope of this document,
but it&#8217;s pretty intuitive. You can consult the documentation of Python&#8217;s
<a class="reference external" href="http://docs.python.org/3/library/unittest.html#module-unittest" title="(in Python v3.4)"><tt class="xref py py-mod docutils literal"><span class="pre">unittest</span></tt></a> library for details.</p>
<p>Note that the return code for the test-runner script is 1 for any number of
failed and erroneous tests. If all the tests pass, the return code is 0. This
feature is useful if you&#8217;re using the test-runner script in a shell script and
need to test for success or failure at that level.</p>
</div>
<div class="section" id="s-speeding-up-the-tests">
<span id="speeding-up-the-tests"></span><h3>Speeding up the tests<a class="headerlink" href="#speeding-up-the-tests" title="Permalink to this headline">¶</a></h3>
<p>In recent versions of Django, the default password hasher is rather slow by
design. If during your tests you are authenticating many users, you may want
to use a custom settings file and set the <a class="reference internal" href="../../ref/settings.html#std:setting-PASSWORD_HASHERS"><tt class="xref std std-setting docutils literal"><span class="pre">PASSWORD_HASHERS</span></tt></a> setting
to a faster hashing algorithm:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="n">PASSWORD_HASHERS</span> <span class="o">=</span> <span class="p">(</span>
    <span class="s">&#39;django.contrib.auth.hashers.MD5PasswordHasher&#39;</span><span class="p">,</span>
<span class="p">)</span>
</pre></div>
</div>
<p>Don&#8217;t forget to also include in <a class="reference internal" href="../../ref/settings.html#std:setting-PASSWORD_HASHERS"><tt class="xref std std-setting docutils literal"><span class="pre">PASSWORD_HASHERS</span></tt></a> any hashing
algorithm used in fixtures, if any.</p>
</div>
</div>
</div>


          </div>
        </div>
      </div>
      
        
          <div class="yui-b" id="sidebar">
            
      <div class="sphinxsidebar">
        <div class="sphinxsidebarwrapper">
  <h3><a href="../../contents.html">Table Of Contents</a></h3>
  <ul>
<li><a class="reference internal" href="#">Writing and running tests</a><ul>
<li><a class="reference internal" href="#writing-tests">Writing tests</a></li>
<li><a class="reference internal" href="#running-tests">Running tests</a><ul>
<li><a class="reference internal" href="#the-test-database">The test database</a></li>
<li><a class="reference internal" href="#order-in-which-tests-are-executed">Order in which tests are executed</a></li>
<li><a class="reference internal" href="#rollback-emulation">Rollback emulation</a></li>
<li><a class="reference internal" href="#other-test-conditions">Other test conditions</a></li>
<li><a class="reference internal" href="#understanding-the-test-output">Understanding the test output</a></li>
<li><a class="reference internal" href="#speeding-up-the-tests">Speeding up the tests</a></li>
</ul>
</li>
</ul>
</li>
</ul>

  <h3>Browse</h3>
  <ul>
    
      <li>Prev: <a href="index.html">Testing in Django</a></li>
    
    
      <li>Next: <a href="tools.html">Testing tools</a></li>
    
  </ul>
  <h3>You are here:</h3>
  <ul>
      <li>
        <a href="../../index.html">Django 1.7.8.dev20150401230226 documentation</a>
        
          <ul><li><a href="../index.html">Using Django</a>
        
          <ul><li><a href="index.html">Testing in Django</a>
        
        <ul><li>Writing and running tests</li></ul>
        </li></ul></li></ul>
      </li>
  </ul>

  <h3>This Page</h3>
  <ul class="this-page-menu">
    <li><a href="../../_sources/topics/testing/overview.txt"
           rel="nofollow">Show Source</a></li>
  </ul>
<div id="searchbox" style="display: none">
  <h3>Quick search</h3>
    <form class="search" action="../../search.html" method="get">
      <input type="text" name="q" />
      <input type="submit" value="Go" />
      <input type="hidden" name="check_keywords" value="yes" />
      <input type="hidden" name="area" value="default" />
    </form>
    <p class="searchtip" style="font-size: 90%">
    Enter search terms or a module, class or function name.
    </p>
</div>
<script type="text/javascript">$('#searchbox').show(0);</script>
        </div>
      </div>
              <h3>Last update:</h3>
              <p class="topless">Apr 02, 2015</p>
          </div>
        
      
    </div>

    <div id="ft">
      <div class="nav">
    &laquo; <a href="index.html" title="Testing in Django">previous</a>
     |
    <a href="../index.html" title="Using Django" accesskey="U">up</a>
   |
    <a href="tools.html" title="Testing tools">next</a> &raquo;</div>
    </div>
  </div>

      <div class="clearer"></div>
    </div>
  </body>
</html>